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THE FOLLOWING SPECIFICATION DESCRIBES 
THE NATURE OF THIS INVENTION :- 


• This invention relates a method and apparatus for develops and 
maintenance of software systems. 

Particularly, this invention relates to model repositories, which play a 
central role in the development and maintenance of large enterprise 
software systems. 

A complex software system has many facets, many levels of abstraction 
«.d many views, like analysis view, design view, GUI view, databas* 
v.ew, archrtectura, view, and the like. A model repository is required to 
prov.de modeling abstractions to capture all these views in a consistent 
manner. 

There are many commercial repository systems that provide 
extensibility around standard methodologies like Unified Modeling 
Language (UML), Entity Relationship (ER) modeling, etc They 
typtcally also package visual modeling tools that support these standard 
methodologies either directly or in the form of a bridge to third party 
modeling tools (e.g.: Rational Rose). 

An important aspect of modeliug is the ability t0 view and edit models 
using a diagrammatic notation. 

However, they do not provide any built-in s „p port „,„, enables 
users to easily specify visual diagrammatic notation for modeling 
abstracts introduced by them. They either have to be content with a 
genenc, non-diagrammatic interface or build a graphical system from 
scratch tf tbey want to provide visual modeling capability ,„ abstractions 
mtroduced by them. This has long been an area where generic repository 


systems have been weak. Though they provide strong model 
extensibility features, the prior art apparatus and method do not provide 
any built-in support for rendering these extended models in a visual, 
diagrammatic language. This is seen as one of the handicaps affecting 
their wider acceptance. 

In the prior art known to the invention, there is no standard modeling 
methodology that addresses all these aspects. 

To overcome this in the prior art, an extensible meta modeling 
framework is provided in model repositories that enables users to extend 
the modeling system with abstractions of their own. i 

A principal object of this invention is to provide a method and appiaratus 
that enables meta-model driven repository systems to provide a 
programmable visual modeling framework that enables end-users to 
specify a concrete graphical notation for abstract models, without having 
to program them from scratch. 

The invention will now be described with reference to the 
accompanying drawings in which 

Figure 1 illustrates a modeling framework in accordance with this 
invention; 

Figure 2 illustrates an example of a meta model which forms the bases 
for creating models in accordance with the framework of Figure 2; 
Figure 3 is a block diagram of a diagram model in accordance with this 
invention; 


Figure 4 is a table showing the objects, association and properties 

contained in the meta model of figure 2; 

Figure 5 Symbol definition in accordance with this invention; 
Figure 6 Annotation definition in accordance with this invention; 
Figure 7 ConnectorEnd Definition in accordance with this invention; 
Figure 8 Connector Definition in accordance with this invention; 
Figure 9 A template for mapping a symbol icon to an object in the 
model in accordance with this invention; 

Figure 10 A template for mapping a container with containees : in 
accordance with this invention; 

Figure .11 A template for defining an association connector in 
accordance with this invention; 

Figure 12 A template for defining an object connector in accordance 
with this invention: 

Figure 13 A template for defining a junction connector in accordance 
with this invention; and 

Figure 14 shows a template for defining Nary connector in accordance 
with this invention. 

Referring to the drawings the modeling framework (mappable to MOF) 
for generic, extensible repository systems, in accordance with this 
invention is shown in Figure 1 of the drawings and is self explanatory. 

Figure 2. of the accompanying drawings shows a Meta meta model. The 
meta meta model (figure 2) is the base model. It is the schema for 
modeling meta models. The meta meta model is capable of describing 
itself, i.e., it can model itself. It is the root of the instantiation hierarchy. 
The meta meta model consists of objects, associations and properties 
shown in the table of Figure 4. 


A m.eta model is an instance of the m eta m eta model. It consists of Meta 
Objects with associated Meta Properties, and Meta Associations defined 
between Meta Objects. A meta model defines the structure and 
semantics for the information system model (e.g.: UML meta model). 

An information system model, also referred to as the user model, is an 
instance of a meta model. It captures the description of the information 
system from various points of view as specified by the meta model (e.g.: 
UML model of a banking system). 

" * • 

The above modeling framework is abstract enough to be able to support 
modeling techniques like UML, ER, etc. 

■ *' ,' 
i 

• '.i 

A generic programmable diagramming framework, using the, above 
modeling framework as the reference is hereinafter described. 

In the first instance is described a model for diagramming, then a 
language for specifying visual attributes of diagram elements, a 
language for mapping diagram elements to meta-model elements, and 
finally a generic diagram drawing tool that interprets these 
specifications. 

A diagram model created in accordance with the teachings of this 
specification is shown in Figure 3 of the drawings. 

A diagram can be conceptualized as a set of connected symbols. A 
symbol can have text fields; a symbol can contain other symbols; a 
connector connects two symbols; a connector can have annotations. 
There is considerable similarity in structure between the meta-meta 
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. For each of the commands various options like line style, color, width, 
fill pattern, etc can be specified. 

Boundary^ section specifies the boundary of the symbol. It consists of a 
polygon whose vertices are specified. The polygon is to enclose the 
shape of the symbol. Connector head and tail are drawn upto the 
polygon edges. 

The Annotation definition is shown in Figure 6. This drawing describes 
the syntax to be used to define an annotation which will be used as part 
of the connector definition. 
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Figure 7 shows ConnectorEnd Definition in accordance with this 
invention. 

In the property section, one can specify properties like background 
color, etc. In shape section, one can specify the drawing commands 
(listed above) to draw the shape of the annotation. 

Figure 7 describes the syntax to be used to define a connector head or 
tail (referred to as connector end) which will be used as part of the 
connector definition. The syntax is identical for both. The head and tail 
will be drawn inside a rectangle whose dimensions have to be specified. 
Drawing commands are the same as the ones used in symbol definition. 

Figure 8 shows Connector Definition in accordance with this invention 
This drawing describes the syntax to be used to define a connector. 
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The symbolprop section is for specifying which properties / associated 
objects of the repository object are to be displayed along with the icon in 
the diagram. 

By using list-control, the associated object's information can be shown 
in a list box having multiple columns. 

Figure 10 shows a template for mapping a container with containees : in 
accordance with this invention. 

In Figure 10 the symbol can contain other symbols is specified. It also 
specifies the meta association between the m eta-object mapped, to^the 
container symbol and the meta-object mapped to the containee symbol. 

Figure 11 shows a template for defining an association connector in 
accordance with this invention: Figure 11 shows a method by which this 
invnetion maps a connector (defined already in the diagram file) with a 
repository association .The sourceSymbol and destinationSymbol have to 
be symbols already defined in the current map file. The head and tail are 
optional. Connector Label too is optional and appears alongside the 
connector in the diagram. 

Object Connector specification 

Figure 12 shows a template for defining an object connector in 
accordance with this invention: 

The object connector specification is for associating a connector symbol 
(specified in diagram file ) with an object connector (specified as a meta 
object in the repository ). The first three specifications are the same as 
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.symbol (has to be defined previously in the map file) and the diagram 
connector to be used to connect the parent symbol to the junction box - 
this will overwrite the default if there is one specified. This is an 
optional specification and if not specified, the default specification given 
in the beginning will be taken. 

The head specification is used as a filter to select the connector-end for 
the connector from the junction-box to the parent. The filtering is based 
on a logical expression involving property values; when the expression 
evaluates to TRUE, the corresponding connector-end is used. It is 
possible to specify a default connector-end when no expression is 
satisfied. The child specification (there can be more than one of this 
kind) identifies the child symbol ( has to be defined previously in the 
map file ) and the connector to be used to connect the child to the 
junction box. The child specification also specifies whether the 
connection between the child and the parent in the repository is a meta 
association or there is another object through which the parent and child 
connect to each other. Accordingly, the relevant information has to be 
entered as in the case of object connector. The connectorlcon 
specification is used to specify the diagram connector to be used for the 
connector between the child symbol and the junction box - this will 
overwrite the default if there is one specified. This is an optional 
specification and if not specified, the default specification given in the 
beginning will be taken. 

The tail specification is used as a filter to select the connector-end for 
the connector from the junction-box to the child. The filtering is based 
on a logical expression involving property values; when the expression 
evaluates to TRUE, the corresponding connector-end is used. It is 


possible .„ specify . drfaltlt connector-end ^ no ^ 
satisfied. 


Figure ,4 shows a template for defining Nary connector m ^ 
with this invention. 

The Nary connector shown in Fignre 14 can be nsed ,„ represent 
assertions in case where a particute meta object is linked with a 
■umber of other meta objects through independent associations Nary 
connector can have many parents and many children. All parents are 
connected to all children with independent associations. 

It Use, the method and apparatns of this invention can create a generic 
dtagram drawing ,„„, that - mtKfMt &t specfficalj()lls ^ fc ^ 
drawings . 

1. The drawing tool supports a drawiog sheet window and an icon palette 
The ,con palette is populated with icons for symbols and connectors as 
defined in the diagram specification file. 

2. When a symbol icon is picked from the icon palette and placed on the 
drawutg sheet, a user can draw the symbol as specified in the diagram 
specfication file, and the method allows i, «o be mapped to a model 
element which is an instance of the meta-object as specified m the map 
file. It ,s now made possible to select an „i S (mg model element or 
create a new model element. Model element selections respect the 
filtermg constraints specified in the map file. The symbol's fields (text 
as well as list fields) are populated as specified m the map file 
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3. When a connector icon representing an association connector is picked 
from the icon palette and placed between two symbols, the following 
happens: 

• If the connector is not valid between the symbols, an error message is 
given. 

« If the specified association already exists in the repository, nothing 
needs to be done, otherwise the association is added in the repository. 

4. When a connector icon representing an object connector is picked from 
the icon palette and placed between two symbols, the following 
happens: 

• If the connector is not valid between the symbols, an error message is 
given. 

• If there already exists an object with associations as specified in the map 
file between the two objects represented by the symbols, then nothing 
needs to be done, otherwise a new object and the required associations 
need to be created in the repository. 

5. When a connector icon representing a junction connector is picked up 
and placed between a junction box and a parent symbol, the following 
things happen: 

• If the junction box has no connected child symbols, then nothing needs 
to be done. If the junction box has connected child symbols, then 
associations need to be created between the objects represented by the 
parent symbol and each of the child symbols if these associations do not 
already exist. 

6. When a connector icon representing a junction connector is picked up 
and placed between a junction box and a child symbol, the following 
things happen: 
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• If the junction box has no connected parent symbol, then nothing needs 
in be done. If the jnnctton box has a connected parent symbol; then an 
assoctatton needs to be created between the object represented by the 
parent symbol and the object represented by the child symbol if the 
association does not already exist. 
7. When a connector icon representing an n-ary connector is placed 
between a parent and a child symbol, specified association or an object 
with appropriate associations is created between the objects representing 
the parent and the child. When an n-ary connector is placed between , 
parent symbol and an n-ary edge, specified associations or objects with 
..appropriate associations are created between the object representing the 
..parent and the objects represented by each of the child symbols. 

8. For all connector types (association, object, jnnction and n-ary) 
annotations are filled as specified hr the map file and connector ends are' 
attached as specified. 

9. When a containee symbol is placed inside a container symbol an 
association, as specified in the map file is created between the objects 
representing the container and the containee symbols. 

The above points specify how the diagrammer tool can interpret the 
diagram and map specification files. In addition, it provides common 
behavior like, grouping of symbols, copy/paste, move, alignment, etc. 

Advantages of the invention 

1- Programmable diagramming feature greatly enhances the productivity of 
repository implementation teams by enabling them to quickly implement 
diagrammatic notations for ever-evolving modeling abstractions. 

2. It enables end-users to quickly implement visual modeling notations of 
their choice for enhanced meta-models, thus allowing them to fully 
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utilize and exploit the built-in extensibility features of model repository 


The proposed diagram model reflects the structure of the meta-m eta- 
model, thus providing a close m atch between modeling abstractions and 
diagramming notations. 

Although the invention has been described in terms of particular 
embodiments and applications, one of ordinary skill in the art, in 
light of this teaching, can generate additional embodiments and 
modifications without departing from the spirit of or exceeding 
the scope of the invention. Accordingly, it is to be understood that 
the drawings and descriptions herein are proffered by way of 
example to facilitate comprehension of the invention and should 
not be construed to limit the scope thereof. 


systems. 



Dated this 24th day of July 2001 


Of R K Dewan & Co 


Applicants 1 Patent Attorney 
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Figure 1- Modeling Framework 
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Figure 2- Meta meta model 
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Figure 3 - Diagram Model 
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Objects in Meta Meta 
Model 

Properties of Object 

MetaObject 

Name, Description, AbstractConcerte 

MetaProperty 

DataType = Char, Number, Binary 
Size = Size of Char String and Number 

MetaAssociation 

Forward and Reverse Name 

Source and Destination Optionality = Association is optional or 

mandatory for source or destination object 

Source and Destination Cardinality = One or Many 

Owner of the Association = Source or destination object is the 

owner of the association 


Associations in Meta Meta Model 

Properties of Association 

MetaObject Inherits From 
MetaObject 

A MetaObject inherits associations and properties 
from another MetaObject. 
Many to Many; Optional 

MetaObject Has MetaProperty 

MetaObject has MetaProperties. 
One to Many; Optional 

MetaObject SourceOf 
MetaAssociation 

MetaObject is source of a MetaAssociation. 
One to Many; Mandatory for MetaAssociation 

MetaObject DestinationOf 
MetaAssociation 

MetaObject is destination of a MetaAssociation. 
One to Many; Mandatory for MetaAssociation 


Figure - 4 
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SYMBOL Name, Iconld FrameX, FrameY { 
Property Section 
Shape Section 
Boundary Section 

} 


LINE StartX, StartY, EndX, EndY [: Options]; 

RECTANGLE TopLeftX, TopLeftY, Width, Height [: Options]; 

RRECTANGLE TopLeftX, TopLeftY, Width, Height, RWidth, RHeight [: Options]; - 

rounded rectangle 

ELLIPSE TopLeftX, TopLeftY, Width, Height [: Options]; 

ARC TopLeftX, TopLeftY, Width, Height, StartAngle, EndAngle [: Options]; 

CHORD TopLeftX, TopLeftY, Width, Height, StartAngle, EndAngle [: Options]; 

PIE TopLeftX, TopLeftY, Width, Height, StartAngle, EndAngle [: Options]; 

POLYGON x1 , y1 , x2, y2, x3, y3 f, xn, yn] [: Options]; 

BITMAP "BmpName", TopLeftX, TopLeftY, Width, Height f: Options] 

TEXT Textld, TopLeftX, TopLeftY, Width, Height, InitText, MaxChar [: Options] 

TEXT fields are used for displaying properties of objects. 
LIST Listld, TopLeftX, TopLeftY, Width, Height [: Options] 

LIST fields are used for displaying multi-column lists 



Figure 5 - Symbol Definition 
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ANNOTATION Name, Iconld FrameX, FrameY { 
Property Section 
Shape Section 

} 

Figure - 6 Annotation Definition 


CONNECTOREND Name, Iconld, FrameX, FrameY, AttachX, AttachY { 
Drawing commands 

} 

Figure - 7 ConnectorEnd Definition 


CONNECTOR Name. Iconld { 
Property Section 

} 

Figure - 8 Connector Definition 
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symbol <symbol> { 

icon = <lconld> 

object = <repos meta object name> 
objectprop { 


<repos meta prop name> = <value> .... 


symbolprop { 

<fieldld> = prop(<repos meta prop name>) | 

assoc(<repos object name> <repos meta assoc name>) I 

script fOSC file name") ... 
[listControl "<fieldld> M 

{ 

[assocExpr = <repos meta assoc name>.<repos meta object 
name>.[<repos meta 

assoc name>.<repos meta object name>...] 


cofSpecs = 
{ 

"<column header>" = <repos meta prop name> | <repos 
meta assoc name>.<repos meta object name>. [<repos meta assoc 
name>.<repos meta object name>...].<repos meta prop name> I 

script ("script file name") 


Figure - 9 

Template for mapping a symbol icon to an object in the model 


} 


}] 
} 


} 
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object connector <connector> 
{ 

connectorlcon = <Connector lconld> 

sourceSymbol = <symbol> [<symbol>...] 
destinationSymbol = <symbol>[<symbol>...] 
object = <repos meta object name> 
objectprop 
{ 

<repos meta prop name> = <value> .... 

} 

sourceAssociation = <repos meta assoc name> 
destAssociation = <repos meta assoc name> 
head 
{ 

<repos meta prop value expression> => <ConnectorEnd lconld> .... 

[ConnectorEnd Iconld] 

} 

tail 

{ 

<repos meta prop value expression^ => < ConnectorEnd Iconld > ..... 
[ConnectorEnd Iconld] 

[connectorLabef = "<value>" | <repos meta prop name> | script fscript file 
name") ] 

[connectorLabel { 

"<Annotation lconld>" = "-cvalue^ | 

"<Annotation lconld>" = <repos meta prop name> | 

"<Annotation lconld>" = script ("script file name") 

}] 

} 

Figure - 12 Template for defining an object connector 
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■ITITA COMSULTAHcy servlcbs 

NAME :(TATA SONS LIMITED) 

NO. / MUM/ 01 


- NO. OF SHEETS : 10 
SHEET NO. ; 7 


PROVISIONAL SPECIFICATION 


containerSpec <symbol> { 
container { 

symbol = <symbol> [<symbol> ...] 

containee { 

symbol - <symbol> [<symbol> ...] 
association = <repos meta assoc name> 

[containee { 

symbol = <symbol> [<symbol> ...] 
association = <repos meta assoc name> 


Figure - 10 Template for mapping a container with containees 


association connector <connector> { 

connectorlcon = <Connector lconid> 
sourceSymbol = <symbol> [<symbol>...] 
destinationSymbof = <symbol> [<symbol>...] 
association = <repos meta assoc name> 


[connectorLabel = "<value>" | 

scnpf ("script file name") 

1 

[connectorLabel { 

"<Annotation lcon!d>" = "<value>" | 
"<Annotation lcon!d>" = scnp/("script file name") 


}] 

} 

Figure - 1 1 

Template for defining an association connector 


} 


head - <ConnectorEnd lconld> 
tail = < ConnectorEnd Iconld > 
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NAME :(TATA SONS LIMITED) NO. OF SHEETS : 1 0 

NO. : /MUM/01 SHEET NO. : 9 

»■ 

PROVISIONAL SPECIFICATION 


oneToMany J unction <symbol> 
{ 

icon - <lconld> 

[connectorlcon = <Connector !conld>] 

parent 

{ 

symbol = <symbol>[<symbol>...] 
[connectorlcon = < Connector Iconld >] 
head -» 
{ 

<repos meta prop value expression>=> <ConnectorEnd 


lconld> .. 


} 

child { 


Iconld > 


[ConnectorEnd Iconld] 


symbol = *symbol>[<symbol>...] 
association = <repos meta assoc. name> | 
objectConnector { 

object = <repos meta object name> 

objectprop { 

<repos meta prop name> = <value> .... 

} 

parentAssociation = <repos meta assoc name> 
childAssociation = <repos meta assoc name> 

} 

[connectorlcon = < Connector Iconld >] 
fa/7{ 

<repos meta prop value expression>=> < ConnectorEnd 


[ConnectorEnd Iconld] 


Figure - 13 Template for defining a junction connector 
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TATA CONSULT ANCy £Zf?Vl££S 

[TATA SONS LIMITED; NO. OF SHEETS : 10 

/MUM/ 01 SHEET NO : 10 

PROVISIONAL SPECIFICATION 


naryConnector <conneptorName> { 
icon = "<Connector lconId>" 
. parent { 

symbol = <symbol> [<symbol> ...] 

[head = "<ConnectorEnd lcon!d> M ] 

[head{ w <ConnectorEnd lconld> M }] 
} • 
child 

{ 

symbol = <symbol> [<symbol> ...] 
association = <repos meta assoc name> | 
objectConnector { r 

object = <repos meta object name> 

[objectprop { 

<repos meta prop name> = "<value> M ... 

}] 

parentAssociation - <repos meta assoc name> 
childAssociation = <repos meta assoc name> 

} 

[tail = "<ConnectorEnd lconld> M ] 
\tail{ 

<repos meta prop value expression => "<ConnectorEnd 

lconld>" ... | 

"<ConnectorEnd iconid>" 

} 
1 

} 


Figure - 14 Template for defining Nary connector 
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